[新機能]VersionsやContractsでガバナンスを効かせつつ複数のdbt project間でModel参照が可能となる「dbt Mesh」を試してみた

さがらです。

現地時間10月16日～10月19日で、dbt Coalesceが開催されました。

基調講演で発表された新機能については、下記のブログが参考になります。

この基調講演で、VersionsやContractsを用いてガバナンスを効かせつつも複数のdbt project間のModelをref関数で参照ができる仕組みとして「dbt Mesh」が発表されました。　※2023年10月27日時点ではパブリックプレビューです。

早速試してみたので、本記事でその内容をまとめてみます。

dbt Meshとは

まず、dbt Meshという用語だけを聞いてもわかりづらいと思いますので、簡単にどういう概念なのかを説明します。

dbtは小規模な企業から大規模な企業まで幅広い企業で使われています。このとき、大規模な企業において、単一のdbt projectで開発・運用しようとしていこうとすると、以下のような問題が起きます。

• Model数が多く、コンパイルなどに時間がかかっている
• 汎用的なデータモデルも各部署ごとのマート的なデータモデルも単一のdbt projectで管理されるため、Gitの承認フローが煩雑になっている

こういった問題を解決するにはdbt projectを分離して管理するのが一つの案としてあるのですが、これまでのdbtではdbt projectを跨いだ依存関係の構築方法が煩雑で正直現実的なものではありませんでした。（より具体的には、この記事のように親dbt projectをpackageとしてインストールする方法）

そこで効率よく複数のdbt projectの管理を行いたい際に役立つのが、dbt Meshです！

dbt Meshを導入することで、以下のようなメリットを得ることができます。

• ref関数で他のdbt projectのModelを簡単に参照できる
• 上流のdbt projectでVersionsを使うことで、下流のdbt projectに影響のある大規模な変更もリスクを抑えて行うことができる
• dbt Explorerを用いることで複数のdbt projectに跨って、各Modelのリネージ、Descriptionなどの情報、source freshnessの情報、関連するsnapshotの情報を参照することができる

より詳しくは下記の公式ドキュメントもご覧ください。

試す内容

下記の公式Docに記載のある、dbt Labs社が用意したdbt Meshテスト用のリポジトリ3つを用いてdbt Cloud上で3つdbt projectを生成し、どのようにdbt Meshが機能しているのかを確認してみます。

forkした3つのリポジトリはこちらです。

• jaffle-shop-mesh-platform
• jaffle-shop-mesh-finance
• jaffle-shop-mesh-marketing

検証環境

• dbt Cloud：Enterpriseエディション　※dbt Mesh機能はdbt CloudのEnterpriseエディションの利用が前提となっている機能です
• 各Environmentのdbtのバージョン：1.6

事前準備

dbt Cloud上で3つのdbt projectをセットアップ

まず、dbt Cloud上で3つのdbt projectをセットアップします。

Production Environmentを作り、全Seed・Modelを実行

続いて、Production Environmentで、以下の順番でdbt buildコマンドを実行するジョブを実行します。この順番で実行しないと、エラーが発生してしまうので注意です！

1. jaffle-shop-mesh-platform　※dbt seed、dbt buildを実行
2. jaffle-shop-mesh-finance　※dbt buildのみ実行
3. jaffle-shop-mesh-marketing　※dbt buildのみ実行

また、Generate docs on runにチェックを付けておくことで、後述するdbt Explorerでより多くの情報を得ることができるようになるため、チェックを付けて実行しておくようにします。

確認その１：dbt projectを跨いだref関数について

dbt projectを跨いだref関数はどのように動くかを確認してみます。

まず大前提として、別のdbt projectを参照したい場合は、dbt projectのディレクトリ直下の階層でdependencies.ymlを作成しておく必要があります。　※今回使用するサンプルリポジトリでは最初から作成済。

例えば、jaffle-shop-mesh-marketingにおいては、下図のようにjaffle-shop-mesh-platformとjaffle-shop-mesh-financeを参照するように定義がされています。

この上で、jaffle-shop-mesh-marketingのdbt projectのcustomers.sqlを見てみます。

customers.sqlは、jaffle-shop-mesh-financeのdbt projectで定義されているorders.sqlとorders_items.sqlをref関数で参照しています。

customers.sqlをIDE上で開いてみると、jaffle-shop-mesh-financeで定義されているModelへのリネージも問題なく生成され、コンパイルされたSQLを見ると、Production Environmentとして設定したスキーマ上のテーブルが参照されています。

確認その２：dbt docs generateを行うとドキュメントはどのように見えるか

次に、dbt docs generateをProduction Environmentでジョブを実行する際に行い、ドキュメントを生成するとどのように見えるかを確認してみます。

今回用いているdbt projectでは最下流に位置するjaffle-shop-mesh-marketingで生成されるドキュメントで、内容を確認してみます。

結果としては、ドキュメント上のprojectsタブで上流に該当する jaffle-shop-mesh-platformとjaffle-shop-mesh-financeのModelが、ドキュメント生成時に都度変わるようになっており、ちょっと不安定な挙動でした・・・ここは今後のアップデートに期待したいところです。

（ちなみに、ドキュメントを生成したdbt projectであるjaffle-shop-mesh-marketingで定義しているModelはきちんとドキュメントに含まれていました。）

• １回目のドキュメント生成

• ２回目のドキュメント生成

確認その３：dbt Explorerではどのように見えるか

確認の最後に、同じくCoalesce 2023で発表されたdbt Explorerを使って、dbt Meshを使って複数のdbt projectに跨った構築をしている場合にどのように見えるかを確認してみます。

dbt Explorerの起動方法

任意のdbt projectを選択している状態で、画面上のExploreを押します。

すると、下図のようにdbt Explorerが立ち上がります。

選択しているdbt project内部でのリネージを確認する

dbt Cloud上で選択しているdbt projectにおいて、各Model間の関係性をリネージで見てみます。

リネージを見たい場合は、Explore Lineageを押せばOKです。

すると、下図のように選択したdbt projectにおけるSeed・Source・Model間のリネージが表示されます。

ここで、Modelの右上に「２」のような表記がされているModelを押してみます。すると、「このModelは別の２つdbt projectで参照されているよ」ということがわかります。

画面の右側に、押したModelの詳細情報もでてきますね。

各dbt project間の関係性を見る

次に、あるdbt project内でModelの関係性を見るのではなく、dbt project間でどのような関係性があるかをdbt Explorerで見てみます。

任意のdbt projectでdbt Explorerを開いた後に、画面上部のパンくずリストから対象のアカウント名をクリックします。

すると、対象のアカウントにある全てのProjectsの一覧が出てきます。この画面では各プロジェクトにModelやMetricsがどれだけの数あるかもわかりますね。

この状態で、画面右上のLineage viewを押します。

すると、下図のように各dbt project間の依存関係がリネージとして見ることができます。各dbt projectをクリックすると、画面右側にどのようなオブジェクトがあるか概要を見ることもできます。

dbt Explorerの検索機能を確かめてみる

dbt Explorerには検索機能があり、みたいオブジェクトを絞り込む機能があります。

画面左上のSearch for resources欄から、任意のキーワードで検索をかけることができます。

例えば、customerと入れると、Nameにcustomerが含まれるModelとTestの一覧が出てきます。

一方で、今後のアップデートに期待したいところとしては、Descriptionの内容でも検索をできるしてようにしてほしいですね！これが出来れば、dbt Cloudではドキュメントに変わる機能になっていくのではないかと・・・

各リソースの詳細画面ではどのように表示されるかを確かめてみる

次に、各dbt project内での各オブジェクトがどのように見ることができるか、確認してみます。

任意のdbt projectからdbt Explorerで開き、画面左のResourcesから各オブジェクトについてどのように見ることができるかを確認してみます。※サンプルリポジトリに存在するオブジェクトのみ記述

Model

各Modelごとに直近のBuild履歴や、レコード数、Groupを確認可能です。

各Modelの詳細画面を押すと、ドキュメントと同じような形式でリネージやDescription、コード、各カラムの定義や設定されているテスト、を確認可能です。

Groups

Accessを設定するときに使えるGroupについて、どのようなGroupがあり、そのGroupにはどういったModelが含まれるか、を確認可能です。

Macros

対象のdbt Project上で定義されているMacroの一覧を確認可能です。

Tests

対象のdbt projectで定義されているTestの一覧と、対象のTestを無事クリアしているかを確認可能です。

最後に

VersionsやContractsを用いてガバナンスを効かせつつも複数のdbt project間のModelをref関数で参照ができる仕組みとしてリリースされた、dbt Meshを試してみました。

今後のアップデートも期待できる機能ですので、dbtの利用が拡大してきた際にはぜひ試していただきたいです！